2장. 복잡함을 가르는 지도 — 커네빈

출처: 『소프트웨어 설계의 결합 균형』(블라드 코노노프 지음, 장연호 옮김, 제이펍 2026) | 원서: Balancing Coupling in Software Design (Manning) · 입문판·PDF 재구성

코드는 분위기만 — class·def·%s 같은 말은 몰라도 됩니다. 표의 '비유'와 '위험'만 봐도 충분해요.

0. 이 장의 새 단어

대부분의 어려운 말은 0장 용어집에 있다.

여기엔 0장에 없는, 이 장에서 처음 나오는 말 3개만 적는다.

막히면 0장으로 돌아가면 된다.

인과관계 (Causality)

한 문장 뜻 — "이걸 하면 저게 된다"의 연결고리. 원인(내 행동)과 결과(시스템 반응) 사이의 끈이다.

일상비유 — 스위치와 전구. 스위치를 올리면 불이 켜진다. 이 "올리면 → 켜진다"가 인과관계다.

한 줄 예 —

press(switch); // 원인
light_on(); // 결과 — 둘이 끈으로 이어져 있음

미지수(unknown) — 아는 모름 vs 모르는 모름

한 문장 뜻 — 내가 모르는 것. 단, "내가 뭘 모르는지 아는 모름"과 "뭘 모르는지조차 모르는 모름"은 전혀 다르다.

일상비유 — 시험 전. "3단원을 안 봤다"는 건 아는 모름(공부하면 됨). "어디서 나올지 짐작도 안 된다"는 모르는 모름(찍어 봐야 앎).

한 줄 예 —

var known_unknown = "전화번호 형식을 모른다 — 만든 사람한테 물으면 됨"; // 이 값이나 객체를 알게 되는 순간 결합 지점이 됩니다.
var unknown_unknown = "왜 가끔 실패하는지조차 모른다 — 실험해 봐야 앎"; // 이 값이나 객체를 알게 되는 순간 결합 지점이 됩니다.

안전한 실험 (Safe-To-Fail Experiment)

한 문장 뜻 — 실패해도 시스템이 안 망가지는 작은 시도. 결과를 보고 배우려고 일부러 던져 보는 것.

일상비유 — 새 요리법을 1인분만 먼저 만들어 본다. 맛없어도 손해는 1인분뿐. 통째로 10인분 만들었다 망하면 큰일.

한 줄 예 —

deploy_to_staging(change); // 진짜 운영 말고 연습장에서 먼저 — 안전
deploy_to_production(change); // 곧장 운영에 — 망하면 다 같이 죽음

이런 적 있죠?

1장에서 결합은 부품을 묶는 접착제라고 배웠다.

결합이 적이 아니라면, 시스템을 엉망으로 만드는 진짜 범인은 누구일까?

코드를 한참 들여다봐도 "뭘 어디서 고쳐야 하지" 정리가 안 된 적 있죠?

static dynamic Process(dynamic order) // 이 메서드의 입력과 출력이 공개 약속입니다.
{
    db.Query(/* 구현 생략 */); api.Get(/* 구현 생략 */); sms.Send(/* 구현 생략 */); // 이 호출은 두 부품 사이의 연결을 보여 줍니다.
    email.Send(/* 구현 생략 */); pay.Charge(/* 구현 생략 */); cache.Clear(/* 구현 생략 */); // 이 호출은 두 부품 사이의 연결을 보여 줍니다.
    // 한 함수가 외부 6곳에 묶임 — 머리가 꽉 참
}

이렇게 머릿속이 꽉 차는 느낌, 그게 복잡성이다.

그리고 이 장의 진짜 주제는 — 복잡함에도 종류가 있다는 것이다.

어떤 복잡함은 규칙만 따르면 끝이고, 어떤 건 전문가한테 물어야 하고, 어떤 건 직접 해 봐야만 안다.

그 종류를 갈라 주는 지도가 바로 커네빈이다.

이 장에서 딱 4가지만

복잡성 = 인지 부하다. 부품 개수가 아니라, 시스템을 다룰 때 내 머릿속이 얼마나 꽉 차는가다.

복잡성은 주관적이다. 같은 시스템도 초보에겐 복잡하고 전문가에겐 사소하다.

커네빈은 상황을 4가지 + 1로 가른다. 명확(규칙) · 복합(전문가) · 복잡(실험) · 혼돈(도망) · 무질서(어딘지 모름).

도메인을 가르는 기준은 원인과 결과가 얼마나 단단히 이어졌는가다. 단단하면 예측 가능(명확), 느슨하면 예측 불가(복잡·혼돈).

개념 1 — 복잡성은 "머릿속 부담"이다

망가지는 장면

낯선 코드베이스를 처음 열었다.

함수 하나 고치려는데, 이게 어디서 호출되는지, 고치면 뭐가 터지는지 도무지 그림이 안 그려진다.

며칠을 들여다봐도 머리만 복잡하다.

비유 먼저

처음 간 대형 마트.

물건이 어디 있는지 몰라 한참 헤맨다.

단골 마트는 상품 수가 똑같아도 안 헤맨다.

즉 복잡함은 물건 개수가 아니라 내 머릿속 부담으로 정해진다.

비유	코드	위험
처음 간 대형 마트	한 함수가 외부 7곳에 의존	"어디부터 보지" 머리 폭발
단골 마트	한 함수가 입력·출력만 명확	머릿속 가벼움 — 고치기 쉬움

한 문장 정의 — 복잡성은 사람이 시스템과 상호작용할 때 느끼는 인지 부하다. 부하가 클수록 이해·제어·예측이 어렵고, 무엇보다 변경에 더 많은 노력이 든다.

예시 폭격

worked(완성예) — 복잡한 코드:

static dynamic Process(dynamic order) // 이 메서드의 입력과 출력이 공개 약속입니다.
{
    var user = db.Query("SELECT /* 구현 생략 */ WHERE id=%s", order["uid"]); // 이 값이나 객체를 알게 되는 순간 결합 지점이 됩니다.
    var product = api.Get($"/products/{order["pid"]}"); // 이 값이나 객체를 알게 되는 순간 결합 지점이 됩니다.
    sms.Send(user["phone"], "처리 중"); // 이 호출은 두 부품 사이의 연결을 보여 줍니다.
    email.Send(user["email"], "주문 안내"); // 이 호출은 두 부품 사이의 연결을 보여 줍니다.
    pay.Charge(user["card"], order["amount"]); // 이 호출은 두 부품 사이의 연결을 보여 줍니다.
    cache.Clear($"user:{order["uid"]}"); // 이 호출은 두 부품 사이의 연결을 보여 줍니다.
}
// 7개 외부 의존이 한 곳에 — "결제 실패 시 문자 재발송" 하나 바꾸려도 7갈래를 다 따라가야 함

부분완성(빈칸 채우기) — 아래에서 머리가 더 무거운 쪽은?

static dynamic A(dynamic order) // 한 줄짜리 규칙도 호출자가 알게 되는 약속입니다.
{
    return pay.Charge(order); // 계산 결과를 호출자에게 돌려줍니다.
}
void B(object order) { db; api; sms; email; pay; cache; } // 의존 6개
// 인지 부하가 큰 쪽은 ____ 다.   (정답: b)

독립적용 — 다음 코드를 보고 "왜 복잡한가" 한 문장으로 답해 보자.

static dynamic Report() // 이 메서드의 입력과 출력이 공개 약속입니다.
{
    var x = stats.Fetch(); y = ml.Predict(x); z = db.Join(y, users); // 이 값이나 객체를 알게 되는 순간 결합 지점이 됩니다.
    return renderer.Render(z, config.LoadTheme(), session.Locale()); // 화면 렌더링까지 한 줄에 묶여 있어 결합이 큽니다.
}
// 답 예: 한 함수가 통계·머신러닝·DB·설정·세션 5곳에 묶여 있어 한 줄만 봐선 전체를 짐작할 수 없다.

개념 2 — 복잡성은 보는 사람에 따라 다르다

망가지는 장면

선배는 "이거 5분이면 고쳐"라고 한다.

그런데 나는 같은 코드를 사흘째 붙잡고 있다.

같은 코드인데 왜 나만 복잡할까?

비유 먼저

자동차가 고장 났다.

초보 운전자는 며칠을 끙끙대도 원인을 못 찾는다.

노련한 정비사는 진단기 꽂고 5분 만에 잡는다.

같은 고장, 다른 머릿속 부담. 복잡함은 관찰자에 따라 달라진다.

비유	코드	위험
초보 운전자	처음 보는 레거시 코드	사흘 붙잡아도 막막
노련한 정비사	매일 만지는 익숙한 코드	5분이면 파악

한 문장 정의 — 복잡성은 주관적이다. "이 시스템은 복잡하다"는 절대 판정은 없다. 항상 "누구에게 복잡한가"를 물어야 한다.

예시 폭격

잘못된 예 vs 올바른 예 — 복잡도를 말하는 방식:

var verdict_wrong = "이 코드는 복잡하다"; // 누구에게? 빠짐 — 판단 불가
var verdict_right = "신입에겐 복잡하고, 담당자에겐 단순하다"; // 관찰자를 밝힘

미니 시나리오 — "이럴 때 이렇게":

// 상황: 팀원이 "이 모듈 복잡해서 못 고치겠어요" 라고 함
// 잘못된 반응: "별로 안 복잡한데?" (내 기준으로 판정)
// 올바른 반응: "어느 부분이 막혀? 그 지식만 채우면 단순해질 수도 있어" (관찰자 기준 인정)

개념 3 — 커네빈: 상황을 가르는 지도

망가지는 장면

문제가 터졌다.

어떤 사람은 "규칙대로 해"라 하고, 어떤 사람은 "전문가 불러", 또 어떤 사람은 "일단 해 보자"라 한다.

다 맞는 말 같은데, 지금 상황엔 뭐가 맞는 걸까?

비유 먼저

길을 잃었다.

먼저 갈라야 한다.

"지도가 있나 / 길 아는 사람한테 물을까 / 직접 가 볼까 / 일단 위험에서 벗어날까."

상황을 먼저 가르고 나서야 옳은 행동이 정해진다.

비유	코드	위험
갈래 안 가르고 무작정 출발	상황 분류 없이 바로 코드 수정	엉뚱한 방법으로 헛고생
먼저 갈래를 가름	`domain = classify(상황)` 후 행동	상황에 맞는 올바른 대응

한 문장 정의 — 커네빈(Cynefin)은 웨일스어로, 데이브 스노든이 2007년 의사결정 지원 도구로 공식화했다. 상황을 다섯 갈래로 나누고, 갈래마다 다른 의사결정 방식을 고르게 해 준다.

언어 주의 (헷갈리는 두 단어)

영어 "complex"와 "complicated"는 일상에서 같은 말처럼 쓰인다.

커네빈은 둘을 엄격히 나눈다.

"complicated = 복합(전문가에게 물으면 됨)", "complex = 복잡(실험해야 앎)".

이 노트에서도 커네빈의 정의를 따른다.

예시 폭격

worked — 다섯 갈래 한눈에:

var domains = ["명확", "복합", "복잡", "혼돈", "무질서"]; // 이 값이나 객체를 알게 되는 순간 결합 지점이 됩니다.
// 명확=규칙 / 복합=전문가 / 복잡=실험 / 혼돈=도망 / 무질서=어디인지부터 파악

독립적용 — "신호등 앞에서 갈지 말지"는 어느 갈래일까?

// 답: 명확. 녹색=가고 빨강=선다. 규칙이 정해져 있어 고민할 게 없다.

개념 4 — 명확 도메인: 규칙대로 하면 된다

예전 커네빈에서는 '명백한(obvious)' 도메인으로 불렸다.

망가지는 장면

답이 뻔한데도 매번 회의를 잡고 토론한다.

"녹색 신호일 때 가도 될까요?"를 30분 회의로 정한다면 우습다.

비유 먼저

신호등.

녹색이면 간다. 빨강·노랑이면 선다.

결과가 분명하고 예측 가능하다. 원인과 결과가 단단히 이어져 있다.

비유	코드	위험
신호등 규칙	정해진 HTTP 상태 코드 처리	(거의 없음 — 규칙만 따르면 됨)
규칙 무시	"대충 200 이상이면 성공이겠지"	201·301도 통과 — 엉뚱한 처리

한 문장 정의 — 명확 도메인에서는 결과가 분명하다. 의사결정은 감지 → 분류 → 대응. 사실을 모으고(감지), 맞는 규칙을 찾고(분류), 규칙을 따른다(대응).

예시 폭격

잘못된 예 vs 올바른 예 — 상태 코드 처리:

// 잘못된 예: 규칙을 뭉개고 임의 처리
if (status >= 200) // 조건이 참일 때만 아래 결정을 실행합니다.
{
    return success(); // 결과를 호출자에게 돌려줍니다.

}
// 올바른 예: 규칙 테이블대로 분류
if status == 200:   return success(); // 200 = 성공
elif status == 404: return not_found(); // 404 = 없음
elif status == 500: return server_error(); // 500 = 서버 오류

미니 시나리오 — WolfDesk 통합(명확):

// SendSMS(target: PhoneNumber, message)
// PhoneNumber 생성자 문서: "E.164 국제 형식이어야 한다" 라고 명시됨
// 감지: 문서를 읽는다
// 분류: E.164 = "+82-10-..." 같은 국제 표준 형식
// 대응: 그 형식으로 넣는다 — 끝. 고민 없음

개념 5 — 복합 도메인: 전문가에게 물어봐야 한다

망가지는 장면

"이 인덱스 추가해도 괜찮겠지?" 혼자 판단하고 배포했다.

알고 보니 옆 팀이 그 DB를 쓰고 있었고, 그 팀 쿼리가 5배 느려졌다.

물어볼 사람이 있었는데도 안 물은 게 화근이다.

비유 먼저

자동차 고장.

내가 뭘 모르는지는 안다 — "엔진 쪽 문제 같은데 원인을 모르겠다."

그래서 정비사를 찾아간다. 정비사는 안다.

이게 "아는 모름"이다. 모르는 건 알지만, 아는 사람이 있다.

비유	코드	위험
정비사에게 물음	옆 팀 리드에게 영향 확인	(안전) 조언 듣고 결정
안 묻고 가정	"설마 영향 있겠어?" 후 배포	옆 팀 쿼리 성능 폭락

한 문장 정의 — 복합 도메인은 "아는 모름(알려진 미지수)"이다. 내가 뭘 모르는지 알고, 그걸 아는 전문가를 찾을 수 있다. 의사결정은 감지 → 분석 → 대응. 사실을 모으고(감지), 전문가와 상의하고(분석), 조언을 따른다(대응).

예시 폭격

잘못된 예 vs 올바른 예 — DB 인덱스 변경:

// 잘못된 예
add_index("orders", "created_at"); // 옆 팀 쓰는 줄 알면서 그냥 배포

// 올바른 예 (감지→분석→대응)
var queries = find_who_uses("orders"); // 감지: 누가 쓰는지 파악
ask(other_team, "이 인덱스 영향 없어?"); // 분석: 전문가에게 상의
add_index_if_safe("orders", "created_at"); // 대응: 피드백 반영

미니 시나리오 — WolfDesk 통합(복합):

// SendSMS(phoneNumber: string, message)  ← 형식이 string 이라 불명확
// 하지만 모듈 만든 사람에게 연락이 된다
// 감지: 어떤 형식이 필요한지 모름을 인지
// 분석: 작성자에게 "어떤 형식이야?" 묻는다
// 대응: 답변대로 통합 — 전문가 덕에 해결

개념 6 — 복잡 도메인: 실험해 봐야 안다

망가지는 장면

"당연히 파란 버튼이 클릭률 높지" 확신하고 배포했다.

까 보니 파란 버튼 12%, 빨간 버튼 37%였다.

내 직감이 틀렸다. 게다가 물어볼 전문가도 없었다.

비유 먼저

낯선 요리.

레시피도 없고, 만들어 본 사람도 없다.

유일한 방법은 1인분만 만들어 맛보는 것이다. 결과를 보고서야 안다.

이게 "모르는 모름"이다. 뭘 모르는지조차 모르거나, 알아도 아는 사람이 없다.

비유	코드	위험
1인분 시식(안전한 실험)	스테이징·A/B 테스트로 먼저	(안전) 결과 보고 결정
통째로 10인분	실험 없이 운영에 바로 배포	직감 틀리면 전부 손해

한 문장 정의 — 복잡 도메인은 "모르는 모름(알려지지 않은 미지수)"이다. 전문가가 없어 실험만이 답이다. 의사결정은 탐색 → 감지 → 대응. 안전한 실험을 하고(탐색), 결과에서 패턴을 보고(감지), 행동을 정한다(대응).

회고로만 안다. 먼저 해 보고 관찰해야 한다. 실패는 배움의 일부다.

예시 폭격

잘못된 예 vs 올바른 예 — 버튼 색 정하기:

// 잘못된 예
button.Color = "blue"; // "당연히 파랑이 낫겠지" — 근거 없는 확신

// 올바른 예 (A/B 테스트 = 안전한 실험)
static dynamic Assign(dynamic user_id) // 이 메서드의 입력과 출력이 공개 약속입니다.
{
    return "red" if user_id % 2 == 0 else "blue"; // 탐색: 50:50 분배
}
// 감지: 클릭률 수집 (red 37% vs blue 12%)
// 대응: 더 높은 쪽 채택

미니 시나리오 — WolfDesk 통합(복잡)에서 흥미로운 전환:

// SendSMS(phoneNumber: string, ...) + 레거시라 작성자도 소스도 없음
// 탐색: 지역 번호로 → 국제 번호로 → 형식을 바꿔가며 시도
// 감지: 어떤 형식이 성공하는지 관찰
// 대응: 성공한 형식을 표준으로 삼고 문서화
// 전환: 형식을 알아내 문서화하면 → 이제 "내가 전문가" → 복합 도메인으로 승격

독립적용 — 다음은 어느 도메인일까?

// 새 추천 알고리즘이 클릭률을 올릴지 아무도 확신 못 한다. 전문가도 없다.
// 답: 복잡. 실험(A/B·피처 플래그)으로 탐색해야 안다.

개념 7 — 혼돈 도메인: 지금 당장 탈출하라

망가지는 장면

배포 직후, 관련도 없어 보이는 서비스들이 줄줄이 타임아웃으로 죽기 시작한다.

팀원 A는 "로그부터 분석하자"고 한다.

분석하는 20분 사이 장애는 더 번진다.

비유 먼저

불이 났다.

지금 "발화 원인을 분석하자"고 앉아 있으면 안 된다.

일단 밖으로 나가야 한다. 분석은 안전해진 다음 일이다.

비유	코드	위험
일단 대피	운영 장애 → 즉시 롤백	(안전) 멈춘 뒤 원인 분석
불 속에서 토론	장애 중 로그부터 분석	분석하는 사이 더 번짐

한 문장 정의 — 혼돈 도메인은 모든 게 통제 불능이고, 원인과 결과가 분리돼 있다. 의사결정은 행동 → 감지 → 대응. 본능으로 위험에서 벗어나고(행동), 결과를 보고(감지), 안전해지면 다음을 계획한다(대응). 목표는 혼돈에서 복잡 도메인으로 빠져나오는 것이다.

혼돈이 되는 두 경우:

본질적으로 예측 불가 — 주사위, 룰렛. 아무리 실험해도 패턴이 없다.
실험할 시간이 없음 — 화재, 자연재해, 실시간 장애.

예시 폭격

잘못된 예 vs 올바른 예 — 운영 장애 대응:

// 잘못된 예: 혼돈에서 분석부터
analyze_logs(); trace_code(); discuss(); // 20분 흐르고 장애 악화

// 올바른 예: 행동부터, 안전 확보 후 분석
rollback_latest(); // 행동: 직감 믿고 최근 배포 롤백
var status = monitor.CheckAll(); // 감지: 회복됐는지 확인
if (status.IsHealthy()) // 조건이 참일 때만 아래 결정을 실행합니다.
{
    start_post_mortem(); // 대응: 안전해진 뒤 원인 분석
}

미니 시나리오 — WolfDesk 통합(혼돈):

// SendSMS(phone: string, ...) — 같은 형식인데 어떤 땐 성공, 어떤 땐 실패
// 알고 보니 로드 밸런서가 서로 다른 버전 서버로 요청을 뿌리고 있었음
// 결과가 무작위 → 실험조차 의미 없음 → 혼돈
// 대응: 본능을 믿고 NotificationMaster 사용 중단 → 다른 SMS 공급자를 찾는다

개념 8 — 무질서 도메인: 내가 어디 있는지부터 알라

망가지는 장면

문제마다 습관적으로 "전문가에게 물어봐"만 외친다.

그런데 이번 건 혼돈 도메인이라, 전문가도 답을 모른다.

지금 어느 갈래에 있는지조차 모른 채 늘 같은 대응만 한 게 문제다.

비유 먼저

지도를 보는데, 내가 지금 지도의 어디에 서 있는지를 모른다.

길을 고르기 전에 "여기가 어디지?"부터 알아야 한다.

비유	코드	위험
내 위치부터 확인	"원인-결과 보이나? 전문가 있나?" 자문	(안전) 맞는 도메인 찾음
위치 모른 채 출발	항상 같은 대응만 반복	도메인 안 맞아 헛수고

한 문장 정의 — 무질서 도메인은 자신이 어느 도메인에 있는지 인식하지 못하는 상태다. 할 일은 하나 — 지금이 명확·복합·복잡·혼돈 중 어디인지 먼저 파악한다.

참고: 커네빈 최신 버전은 무질서를 "아포리아(aporia, 증거와 반증이 동시에 있어 진실 가리기 어려운 상태)"와 "혼란(confusion, 잘못 분류하고도 그 사실을 모르는 상태)"으로 나눈다. 이 책은 단순화를 위해 둘을 구분하지 않는다.

예시 폭격

잘못된 예 vs 올바른 예:

// 잘못된 예: 위치 파악 없이 습관 대응
always("전문가에게 물어봐"); // 혼돈인데 전문가도 모름 → 막힘

// 올바른 예: 먼저 분류
if 원인_결과_보임:        domain = "명확"; // 이 값이나 객체를 알게 되는 순간 결합 지점이 됩니다.
elif 전문가_있음:        domain = "복합"; // 이 값이나 객체를 알게 되는 순간 결합 지점이 됩니다.
elif 실험_가능:          domain = "복잡"; // 이 값이나 객체를 알게 되는 순간 결합 지점이 됩니다.
else:                   domain = "혼돈"; // 이 값이나 객체를 알게 되는 순간 결합 지점이 됩니다.
act_by(domain); // 도메인 정한 뒤 행동

개념 9 — 도메인을 가르는 진짜 기준: 인과관계 결합

망가지는 장면

"이거랑 이건 둘 다 복잡한 일이야"라고 뭉뚱그렸다.

그런데 하나는 규칙만 따르면 됐고, 다른 하나는 며칠 실험해야 했다.

둘을 같은 통에 넣은 게 실수였다.

비유 먼저

기차 · 오프로드 차 · 보트.

기차는 레일 위를 간다 — 출발점만 알면 도착점이 뻔하다(결합 단단).

오프로드 차는 노면 따라 조금씩 달라진다.

보트는 바람·파도 위라 노련한 선장도 도착점을 장담 못 한다(결합 느슨).

비유	도메인	인과관계 결합
기차(레일)	명확	강하게 결합 — 예측 완전
길 아는 운전사	복합	강하지만 내가 모름 — 전문가는 앎
오프로드 차	복잡	약하게 결합 — 실험해야 앎
거친 바다의 보트	혼돈	분리됨 — 예측 불가

한 문장 정의 — 도메인을 가르는 기준은 원인과 결과가 얼마나 단단히 이어졌는가다. 단단할수록 예측 가능(명확), 느슨할수록 예측 불가(복잡), 끊기면 무작위(혼돈)다. 그래서 복잡성은 행동과 결과 사이의 느슨한 결합에서 나온다.

이것이 저자가 1장에서 결합을 먼저 다루고 2장에서 커네빈으로 넘어온 이유다. 복잡성은 결합 이야기의 연장이다.

예시 폭격

worked — 같은 "DB 인덱스 변경"이 도메인에 따라 달라진다:

// 명확: 내 마이크로서비스만 이 DB를 씀 → 영향이 다 보임
// 복합: 옆 팀도 씀을 알고, 그 팀과 논의 가능 → 전문가 있음
// 복잡: 누가 쓰는지 모름 → 스테이징에서 성능 테스트로 탐색
// 혼돈: 옆 팀 존재도 모르고 테스트도 없음 → 배포 후 장애 → 롤백으로 탈출

독립적용 — 다음을 도메인에 연결해 보자.

// "팀 전용 DB, 이 서비스만 사용" → ____   (명확)
// "레거시 결제 API, 담당자 퇴사, 문서 없음" → ____   (복잡)

더 알아두기 — 커네빈은 코드 너머로도 쓰인다

커네빈은 소프트웨어만의 도구가 아니다.

의료·농업 등 다양한 분야의 의사결정에 쓰인다.

소프트웨어 안에서도 "기능을 직접 만들까, 사서 쓸까(빌드 vs 바이)" 같은 전략 결정에 쓸 수 있다.

한 가지만 기억하자.

모든 어려운 일이 "복잡"인 건 아니다.

전문가에게 물으면 풀리면 복합, 원인-결과가 끊겨 무작위면 혼돈이다.

복잡은 그 사이 — 실험해야만 풀리는 자리에 있다.

단순 규칙

설계 결정을 내리기 전에, 멈추고 "지금 어느 도메인이지?"부터 묻는다.
명확이면 규칙, 복합이면 전문가, 복잡이면 실험, 혼돈이면 일단 탈출, 모르겠으면 도메인부터 파악.
복잡 도메인에서 실험으로 알아낸 지식은 문서로 남겨 다음 사람에겐 복합(전문가 있는 상황)이 되게 한다.

더 해보기

커네빈 공식 포털 — cynefin.io
스노든의 커네빈 소개 원문(2007, Harvard Business Review) — A Leader's Framework for Decision Making
A/B 테스트 개요(원서 각주 참조) — Wikipedia — A/B testing

(검증 2026-05-31 / Tavily+Brave+SearXNG — 위 링크는 2장 딥다이브 노트에서 교차확인)

연습문제

설명. 복잡함을 가르는 지도의 핵심을 처음 듣는 사람에게 한 문장으로 설명하라.
구분. 두 개념(명확한 도메인, 복잡한 도메인)을 실제 예시 하나로 구분하라.
적용. 내 프로젝트나 학습 노트에서 이 장의 개념을 적용해 작게 개선할 지점을 하나 고르라.

부록 A. 쉬운 용어 사전

한글 용어	원문 영문명	아주 쉬운 뜻	이 장에서 나온 위치
명확한 도메인	Clear Domain	원인과 결과가 뻔해서 정해진 답을 적용할 수 있는 상황.	부록 B와 본문 예시
복잡한 도메인	Complex Domain	실험하고 관찰해야 원인과 결과를 알 수 있는 상황.	부록 B와 본문 예시
선형 상호작용	Linear Interaction	한 변경이 어디에 영향을 주는지 따라갈 수 있는 상호작용.	부록 B와 본문 예시
복잡한 상호작용	Complex Interaction	한 변경의 영향이 예상 밖으로 번지는 상호작용.	부록 B와 본문 예시

부록 B. 헷갈리는 개념 비교표

A	B	구분 포인트
명확한 도메인	복잡한 도메인	명확한 도메인은 답이 보이고, 복잡한 도메인은 실험해 봐야 안다.
선형 상호작용	복잡한 상호작용	선형은 따라갈 수 있고, 복잡한 상호작용은 예상 밖으로 번진다.

부록 C. 더 읽을 자료

이 장의 더 해보기 섹션 — 이미 모아 둔 공식 문서나 실습 링크가 있으면 여기서 먼저 확인한다.
같은 책의 0장 한눈에 보기 — 용어가 막히면 0장의 용어집과 개념 척추로 돌아간다.
원본 딥다이브판 같은 장 — 입문판을 읽고 큰 흐름이 잡힌 뒤 세부 논리를 더 깊게 확인한다.
이 장의 flashcards.json — 읽은 직후 질문만 보고 답을 떠올리는 회상 연습에 쓴다.

부록 D. 연습문제 풀이

설명 예시. 복잡함을 가르는 지도는 변경이 어디로 번지는지 보고, 필요한 연결과 줄여야 할 연결을 구분하게 해 주는 장이다. 중요한 것은 용어를 외우는 것이 아니라, 이 개념이 어떤 입력·부품·결정에 영향을 주는지 말로 풀어 보는 것이다.
구분 예시. 두 개념(명확한 도메인, 복잡한 도메인)의 차이는 이렇게 잡으면 된다. 명확한 도메인은 답이 보이고, 복잡한 도메인은 실험해 봐야 안다. 실제 사례를 볼 때는 목적, 입력, 실패했을 때의 증상을 따로 적어 보면 헷갈리지 않는다.
적용 예시. 가장 작은 개선부터 고른다. 예를 들어 이름을 더 분명히 하거나, 평가 기준을 한 줄 추가하거나, 직접 알 필요 없는 내부 정보를 감추는 식으로 시작한다. 한 번에 크게 갈아엎는 것보다 작은 변경 하나를 확인하며 진행하는 쪽이 입문 단계에 맞다.

다음 장 예고

다음 장에서는 이 복잡성이 어디서 생겨나는지 — 시스템이 커서인지, 설계 탓인지를 본다.

지금은 "복잡함에도 종류가 있고, 도메인부터 가른다"만 들고 가면 충분하다.

질문

카드를 로딩 중...

답변

클릭하거나 Space를 눌러 뒤집기

0 / 0

학습 진도 0%

← → 이동 Space 뒤집기 R 셔플